Skip to content

fix: support cross-origin iframe snapshots#1048

Open
Zqian007 wants to merge 1 commit intovercel-labs:mainfrom
Zqian007:fix-cross-iframe
Open

fix: support cross-origin iframe snapshots#1048
Zqian007 wants to merge 1 commit intovercel-labs:mainfrom
Zqian007:fix-cross-iframe

Conversation

@Zqian007
Copy link
Copy Markdown

@Zqian007 Zqian007 commented Mar 27, 2026

Summary

Fix cross-origin iframe support in snapshots. The snapshot command now correctly captures content from cross-origin iframes by proactively attaching to untracked iframe targets and falling back to dedicated iframe sessions when same-origin resolution fails.

Why this matters

Previously, cross-origin iframes were silently skipped during snapshots. resolve_iframe_frame_id relies on contentDocument access, which is blocked by the same-origin policy — so any cross-origin iframe would fail and its content would be lost entirely. This meant AI agents working on pages with embedded third-party iframes (e.g. payment widgets, OAuth flows, embedded maps) had no visibility into those frames.

Additionally, Target.attachedToTarget events could arrive before the daemon was ready or be missed entirely, leaving cross-origin iframe targets unregistered in iframe_sessions even when Chrome had already attached to them.

Changes

Rust CLI (cli/src/native/actions.rs):

  • Before taking a snapshot, call Target.getTargets to discover any iframe targets not yet tracked in iframe_sessions
  • Attach to each untracked iframe target via Target.attachToTarget and register its session ID

Rust CLI (cli/src/native/snapshot.rs):

  • Change resolve_iframe_frame_id call from ? (bail on error) to .ok() (treat failure as None)
  • For same-origin iframes: snapshot using the parent session + resolved frameId (existing behavior)
  • For cross-origin iframes: fall back to iterating iframe_sessions and snapshot each via its dedicated session without a frameId

@vercel
Copy link
Copy Markdown
Contributor

vercel bot commented Mar 27, 2026

Someone is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

…n TCP bind (vercel-labs#1041)

On Windows the daemon derives a TCP port from the session name via a
djb2 hash (e.g. "default" → 50838). On many machines this port falls
inside Hyper-V's excluded port range (winnat), causing EACCES on bind
and preventing the daemon from starting.

Changes:
- daemon: try the hash-derived port first; on failure, bind to port 0
  (OS-assigned) and write the actual port to the .port file
- client (connection.rs, stream.rs): read the .port file to discover the
  daemon's actual port, falling back to the hash if the file is absent
- run_daemon: guard .sock file operations with #[cfg(unix)] and add
  .port file cleanup for #[cfg(windows)]

Fixes vercel-labs#390

Co-authored-by: ctate <366502+ctate@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants